Experiments in Theorem Proving and Model Checking for Protocol Veriication ?

نویسندگان

  • Klaus Havelund
  • Natarajan Shankar
چکیده

protocol : THEORY BEGIN File : TYPE = fNONE,ONE,MANYg Msg : TYPE = [# first: bool, last: bool, toggle: bool #] State : TYPE = [# file : File, rn : bool, afile : bool, ... #] The automaton speci cation also changes but this is acceptable since Theorem 1 admits an abstract property pa distinct from the concrete property pc. We omit the details of this new automaton speci cation. In the abstract version of the transition rule Rule write K, for example, the update of K(last) has been changed from K(last) := (head(st)=last) to K(last) := (file(st)=ONE). The update of rn has changed, and the update of K(data) has now disappeared. The abstraction mapping between the concrete state type and the abstract state type is then given by the function abs de ned below. abstraction : THEORY BEGIN A : THEORY = abstract_protocol C : THEORY = protocol abs(s:C.State):A.State = (# file := IF head(s)=nil THEN NONE ELSIF head(s)=last THEN ONE ELSE MANY ENDIF, rn := rn(s)/=0, afile := ahead(s)/=nil, ... #) ... END abstraction The Theorem 1 can now be used to prove the invariant asserted in the theorem concrete correct shown below. concrete_correct : THEOREM AG(C.initial,C.transition)(safe) Recall that Theorem 1 was de ned in the context of a concrete system Sc (protocol in our case), an abstract system Sa (abstract protocol) and an abstraction mapping h (abs) between the two. Theorem 1 tells us that it is su cient to prove the following propositions corresponding to items 1{4 in the theorem. The rst, third and fourth of these are easily proved by the grind proof strategy of PVS. The second proof obligation is the only nontrivial one and it is shown below as transition preserves. 14 % init_preserved : PROPOSITION%A.initial(abs(C.startstate))transition_preserves : PROPOSITIONFORALL (s1,s2:C.State):(I(s1) AND I(s2) AND C.transition(s1,s2))IMPLIESA.transition(abs(s1),abs(s2))% property_preserved : PROPOSITION%FORALL (s:C.State): SAFE(abs(s)) IMPLIES SAFE(s)% abstract_correct : THEOREM%AG(A.initial,A.transition)(safe)The proof obligation transition preserves only requires the abstract sys-tem to simulate a step of the concrete system when a concrete invariant I holdsof the initial and nal states of the transition. Indeed, we do require the use ofa speci c concrete invariant in justifying the abstraction, and this is currentlyproved directly in PVS without the aid of abstraction. We, in fact, reuse thisinvariant from the proof of BRP-PVS in the Section 4.It took two weeks to de ne the abstract protocol and the abstraction map-ping, and to carry out the proof of the main lemma: transition preserves. Ittakes two hours to rerun the proof of this lemma. However, this lemma againuses a number of invariants about the concrete protocol; we need 45 of the 58invariants invented in the original invariant proof in Section 4. Considering theextra two-week e ort in carrying out this abstraction proof, one may concludethat no essential work e ort has been saved by doing the abstraction with modelchecking in comparison with the pure invariant proof. We claim, however, thatthe abstraction gives a good intuition about the functioning of the protocol,since it focuses on control. Also, it is likely that many of the prior invarianceproofs can also be proved via abstraction and model checking.The nal proof obligation abstract correct is proved by means of modelchecking. Using the PVS command model-check, this lemma is proved in 36.7minutes. Our initial experiences in applying the PVS model checker to this ex-ample were not satisfactory. This led us to reformulate the abstract protocolin Murphi and in the CTL model checker SMV, in order to compare executiontimes. In Mur , the veri cation took 28.51 seconds. The main source of e ciencyin Murphi with respect to this example is that it uses an explicit (not symbolic)representation of the state space and only explores the reachable states. Ourinitial de nition of the AG operator was such that it explored all those statesthat could potentially lead to a state violating the invariant in order to check ifthese states included the start state. Obviously, many more states were exploredin this manner.When we apply the SMV model checker [17] to the example, it takes 2.5hours to verify the abstract protocol. When SMV is used with the option `-f',only the `forward' reachable states are examined, and this gives an impressive15 improvement in e ciency taking only 24 seconds | an improvement factor ofnearly 400.6 ObservationsAs a general remark, we want to stress a basic result of the work: to providea nontrivial example/methodology for reasoning about protocols using theoremproving and model checking. Our framework is adequate for deeper studies of theproblems we have encountered, such as the identi cation of suitable invariantsand the design of useful nite-state abstractions.We have found it useful and productive to employ a state exploration toolsuch as Murphi as a prelude to full theorem proving. Murphi was also useful forchecking putative invariants.In [10] a re nement between the protocol and an abstract protocol was de-ned and veri ed. Our contribution has been to reformulate re nement as asafety property by superposing the implementation and speci cation of the pro-tocol. This technique seems simple and yet useful.The in nite state PVS speci cation initially took three man-months to ver-ify. This is comparable to the work in Coq [10] where they were starting from ahand-written proof. We believe though that our proof is more automated thanthe Coq proof: for any invariant proof, once we had identi ed (and included asassumptions) which other sub-invariants it depended on, the proof was auto-matic using a specially designed tactic based on decision procedures. With ourimproved approach of strengthening invariants on the y, we were able to reducethe proof e ort to less than four weeks.Our use of abstraction yields a better understanding of the protocol sinceit extracts out the relevant control skeleton. We hope that a deeper study willreveal systematic techniques for obtaining such abstractions.References1. K. A. Bartlett, R. A. Scantlebury, and P. T. Wilkinson. A note on reliablefull-duplex transmission over half-duplex links. Communications of the ACM,12(5):260, 261, May 1969.2. Rachel Mary Cardell-Oliver. The formal veri cation of hard real-time systems.Technical Report 255, University of Cambridge Computer Laboratory, 1992.3. K.M. Chandy and J. Misra. Parallel Program Design: A Foundation. AddisonWesley, 1988.4. E.M. Clark, O. Grumberg, and D.E. Long. Model checking and abstraction. ACMTransactions on Programming Languages and Systems, 16(5):1512{1542, Septem-ber 1994.5. C. Cornes, J. Courant, J.C. Filliatre, G. Huet, P. Manoury, C Paulin-Mohring,C. Munoz, C. Murthy, C. Parent, A. Saibi, and B. Werner. The Coq proof as-sistant reference manual, version 5.10. Technical report, INRIA, Rocquencourt,France, February 1995. This version is newer than the version used to verify theBRP-protocol in [10].16 6. D. Cyrluk, S. Rajan, N. Shankar, and M. K. Srivas. E ective theorem provingfor hardware veri cation. In Ramayya Kumar and Thomas Kropf, editors, Theo-rem Provers in Circuit Design (TPCD '94), volume 910 of Lecture Notes in Com-puter Science, pages 203{222, Bad Herrenalb, Germany, September 1994. Springer-Verlag.7. Dennis Dams, Orna Grumberg, and Rob Gerth. Abstract interpretation of reactivesystems: Abstractions preserving 8CTL*, 9CTL* and CTL*. In Ernst-RudigerOlderog, editor, Programming Concepts, Methods and Calculi (PROCOMET '94),pages 561{581, 1994.8. M. J. C. Gordon. HOL: A proof generating system for higher-order logic. InG. Birtwistle and P. A. Subrahmanyam, editors, VLSI Speci cation, Veri cationand Synthesis, pages 73{128. Kluwer, Dordrecht, The Netherlands, 1988.9. J. F. Groote and J. C. van de Pol. A bounded retransmission protocol for largepackets. A case study in computer checked veri cation. Logic Group PreprintSeries 100, Utrecht University, 1993.10. L. Helmink, M.P.A. Sellink, and F.W. Vaandrager. Proof-checking a data linkprotocol. Technical Report CS-R9420, Centrum voor Wiskunde en Informatica(CWI), Computer Science/Department of Software Technology, March 1994.11. G. J. Holzmann. Design and Validation of Computer Protocols. Prentice-Hall,1991.12. G. Janssen. ROBDD software. Department of Electrical Engineering, EindhovenUniversity of Technology, October 1993.13. Simon S. Lam and A. Udaya Shankar. Protocol veri cation via projections. IEEETrans. on S.W. Engg, SE-10(4):325{342, July 1984.14. L. Lamport. The Temporal Logic of Actions. Technical report, Digital EquipmentCorporation (DEC) Systems Research Center, Palo Alto, California, USA, April1994.15. C. Loiseaux, S. Graf, J. Sifakis, A. Bouajjani, and S. Bensalem. Property preserv-ing abstractions for the veri cation of concurrent systems. Formal Methods inSystem Design, 6:11{44, 1995.16. N.A. Lynch and M.R. Tuttle. Hierarchical correctness proofs for distributed algo-rithms. In Proceedings of the sixth Annual Symposium on Principles of DistributedComputing, New York, pages 137{151. ACM Press, 1987.17. K.L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, Boston,1993.18. R. Melton, D.L. Dill, and C. Norris Ip. Murphi annotated reference manual, ver-sion 2.6. Technical report, Stanford University, Palo Alto, California, USA, Novem-ber 1993. Written by C. Norris Ip.19. Olaf Muller and Tobias Nipkow. Combining model checking and deduction for I/Oautomata. Draft manuscript, 1995.20. S. Owre, J.M. Rushby, and N. Shankar. PVS: A prototype veri cation sys-tem. In D. Kapur, editor, 11th International Conference on Automated Deduction(CADE), Saratoga { NY, Lecture Notes in Arti cial Intelligence, Volume 607,pages 748{752. Springer Verlag, June 1992.21. S. Rajan, N. Shankar, and M.K. Srivas. An integration of model-checking withautomated proof checking. In Computer-Aided Veri cation (CAV) 1995, Liege,Belgium, Lecture Notes in Computer Science, Volume 939, pages 84{97. SpringerVerlag, July 1995. Long version of this paper is available.17 A Speci cationAutomaton In MurphiNote that the type File and the boundlast are de ned in the implementationautomaton below.Varabusy : boolean; afile : File;ahead : 1..last+1;afirst : boolean; aerror : boolean;Procedure verify_REQ(f:File);Begin assert !abusy;abusy := true; afile := f; ahead := 1;End;Procedure verify_IND(d:Data;i:IndT);Begin assert abusy & !aerror & ahead != nil &d = afile[ahead] &i = (ahead=last ? LAST :(afirst ? FIRST :INCOMPLETE));afirst := (ahead=last); ahead := ahead + 1;End;Procedure verify_IND_ERR();Begin assert aerror;afirst := true; aerror := false;End;Procedure verify_CONF(c:Conf);Begin assert abusy & !aerror &(c=OK -> ahead=nil) &(c=DONT_KNOW -> (ahead=nil|ahead=last)) &(c=NOT_OK -> ahead != nil);abusy := false; aerror := !afirst;ahead := nil;End;B ImplementationAutomaton in MurphiTypeData : boolean;Msg : Recordfirst, last, toggle : boolean;data : DataEnd;Spc : EnumWR, SF, WA, SC, WT2;Conf : EnumOK, NOT_OK, DONT_KNOW;File : Array [1..last] Of Data;Rpc : EnumWF, SI, SA, RTS, NOK;IndT : EnumFIRST, INCOMPLETE, LAST;Constmax : 2; last : 3; nil : last+1;VarK : Msg; K_full : boolean; L : boolean;req : File; req_full : boolean;conf : Conf; conf_full : boolean;spc : Spc; sfirst : boolean;stoggle : boolean; file : File;head : 1..last+1; rn : 0..max;stimer1_on : boolean; stimer1_enabled : boolean;stimer2_on : boolean; stimer2_enabled : boolean;ind_data : Data; ind_indication : IndT;ind_full : boolean; ind_error : boolean;rpc : Rpc; rfirst : boolean; rtoggle : boolean;ctoggle : boolean; msg : Msg;rtimer_on : boolean; rtimer_enabled : boolean;StartstateBegin...End;Ruleset d1 : Data; d2 : Data; d3 : Data DoRule "write_req" !req_full ==>req_full := true; req[1] := d1;req[2] := d2; req[3] := d3;End;End;Rule "read_conf" conf_full ==> conf_full := false; End;Rule "read_ind" ind_full ==> ind_full := false; End;Rule "read_ind_error" ind_error ==>ind_error := false; End;Rule "lose_msg" K_full ==>K_full := false;stimer1_enabled := true; End;Rule "lose_ack" L ==>L := false; stimer1_enabled := true; End;Rule "read_req" spc = WR & req_full ==>req_full := false;For i := 1 To last Do file[i] := req[i] End;head := 1; spc := SF;verify_REQ(req);End;Rule "write_K" spc = SF & !K_full ==>K_full := true; K.first := sfirst;K.last := (head = last);K.toggle:= stoggle; K.data := file[head];spc:= WA; rn := rn+1; stimer1_on := true;End;Rule "read_L" spc = WA & L ==>L := false;If head = last Then spc := SC; Else spc := SF; End;sfirst := (head = last);If !(head = last) Then rn := 0 End;head := head + 1; stoggle := !stoggle;stimer1_on := false; stimer1_enabled := false;End;Rule "write_conf" spc = SC & !conf_full ==>conf_full := true;If head = nil Then conf := OK18 Elsif head = last & rn != 0 Then conf := DONT_KNOW;Else conf := NOT_OK; End;If head = nil Then spc := WR; Elsespc := WT2; sfirst := true; stoggle := !stoggle;stimer2_on := true; rtimer_enabled := true;End;head := nil; rn := 0;verify_CONF(conf);End;Rule "stimer1" stimer1_on & stimer1_enabled ==>If rn = max Then spc := SC; Else spc := SF; End;stimer1_on := false; stimer1_enabled := false;End;Rule "stimer2" stimer2_on & stimer2_enabled ==>spc := WR; stimer2_on := false;stimer2_enabled := false;End;Rule "read_K" rpc = WF & K_full ==>K_full := false;msg.first := K.first; msg.last := K.last;msg.toggle := K.toggle; msg.data := K.data;If !ctoggle | (msg.toggle = rtoggle) Thenrpc := SI; rtimer_on := false;rtimer_enabled := false;Elserpc := RTS;End;End;Rule "write_ind" rpc = SI & !ind_full ==>ind_full := true; ind_data := msg.data;If msg.last Then ind_indication := LAST;Elsif msg.first Then ind_indication := FIRST;Else ind_indication := INCOMPLETE;End;rpc := SA; rfirst := msg.last; ctoggle := true;rtoggle := !msg.toggle;verify_IND(ind_data,ind_indication);End;Rule "write_L" (rpc = SA | rpc = RTS) & !L ==>L := true;If rpc = SA Then rtimer_on := true; End; rpc := WF;End;Rule "write_ind_error" rpc = NOK & !ind_error ==>ind_error := true; rpc := WF; rfirst := true;rtimer_on := true; stimer2_enabled := true;verify_IND_ERR();End;Rule "rtimer" rtimer_on & rtimer_enabled ==>ctoggle := false;If !rfirst Then rpc := NOK; rtimer_on := false;Else stimer2_enabled := true; End;rtimer_enabled := false;End;C InvariantsInvariant "ref_abusy"abusy = (spc = SF | spc = WA | spc = SC);Invariant "ref_afirst"afirst = rfirst;Invariant "ref_aerror"aerror = ((rpc = NOK) |(spc = WT2 & rtimer_on & !rfirst));Invariant "ref_afile"Forall i:1..last Do afile[i]=file[i] Endforall;Invariant "ref_ahead"ahead =((spc = WT2 |(ctoggle -> stoggle=rtoggle)) ? head : head+1);Invariant "spc_1"(spc = WR | spc = SF | spc = SC) -> rpc = WF;Invariant "spc_2"(spc = SF & rn = 0) ->(ctoggle -> stoggle = rtoggle);Invariant "spc_3"spc = WA -> rn != 0;Invariant "spc_4"spc = WT2 & !rtimer_enabled -> !ctoggle;Invariant "spc_5"spc=SC & head = nil ->(ctoggle & stoggle = rtoggle);Invariant "spc_6"spc = SC & head = nil -> rfirst;Invariant "spc_7"spc = WR -> (ctoggle -> stoggle = rtoggle);Invariant "spc_8"spc = WT2 -> rn = 0;Invariant "spc_9"(spc = SC & rn = 0) ->(ctoggle -> stoggle = rtoggle);Invariant "spc_10"spc = SF ->((ctoggle -> stoggle = rtoggle) ->sfirst = rfirst);Invariant "spc_11"spc = WR ->((ctoggle -> stoggle = rtoggle) ->sfirst = rfirst);Invariant "spc_12"spc = WA ->((ctoggle -> stoggle = rtoggle) ->sfirst = rfirst);Invariant "spc_13"spc = SC ->((ctoggle -> stoggle = rtoggle) ->sfirst = rfirst);Invariant "spc_14"spc = WT2 -> sfirst;Invariant "spc_15"spc = WA -> head != nil;Invariant "spc_16"spc = SF -> head != nil;Invariant "rpc_1"(rpc = SI | rpc = SA | rpc = RTS)->spc = WA;Invariant "rpc_2"rpc = NOK->spc = WT2;Invariant "rpc_3"rpc = SI -> msg.last = (head = last);19 Invariant "rpc_4"rpc = NOK -> !ctoggle;Invariant "rpc_5"rpc = SI -> stoggle = msg.toggle;Invariant "rpc_6"(rpc = SA | rpc = RTS) -> stoggle = msg.toggle;Invariant "rpc_7"(rpc = SA | rpc = RTS) ->(ctoggle & msg.toggle != rtoggle);Invariant "rpc_8"(rpc = WF | rpc = RTS) -> rtimer_on;Invariant "rpc_9"rpc = SI -> (ctoggle -> msg.toggle = rtoggle);Invariant "rpc_10"rpc = SI -> msg.data = file[head];Invariant "rpc_11"rpc = SI -> rfirst = msg.first;Invariant "K_1"K_full->(spc = WA & rpc = WF & !L);Invariant "K_2"K_full -> K.last = (head = last);Invariant "K_3"K_full -> K.toggle = stoggle;Invariant "K_4"K_full -> K.data = file[head];Invariant "K_5"K_full -> ((ctoggle -> K.toggle = rtoggle) ->K.first = rfirst);Invariant "L_1"L ->(spc = WA & rpc = WF & !K_full);Invariant "L_2"L -> ctoggle & (!rtoggle) = stoggle;Invariant "stimer1_1"stimer1_enabled->(spc = WA & rpc = WF & !K_full & !L);Invariant "stimer2_1"stimer2_enabled->(spc = WT2 & rpc = WF & !K_full & !L);Invariant "stimer2_2"stimer2_enabled -> rfirst;Invariant "stimer2_3"stimer2_enabled -> rfirst;Invariant "rtimer_1"rtimer_enabled->(spc = WT2 & rpc = WF &!K_full & !L & !stimer2_enabled);Invariant "rn_1"rn != 0 -> spc != WR;Invariant "rn_2"(rn != 0 & ctoggle & stoggle != rtoggle) ->rfirst = (head = last);Invariant "head_1"head = nil -> (spc = WR | spc = WT2 | spc = SC);Invariant "safe_1"spc = WR -> !abusy;Invariant "safe_2"spc = SC -> abusy;Invariant "safe_3"spc = SC -> !aerror;Invariant "safe_4"spc = SC ->(head = nil -> ahead = nil)&((head = last & rn != 0) ->(ahead = nil | ahead = last))&((head = last & rn = 0) -> ahead != nil)&((head < last) -> ahead != nil);Invariant "safe_5"rpc = SI -> abusy;Invariant "safe_6"rpc = SI -> !aerror;Invariant "safe_7"rpc = SI -> ahead != nil;Invariant "safe_8"rpc = SI -> msg.data = afile[ahead];Invariant "safe_9"rpc = SI ->((msg.last = (ahead = last)) &(msg.first = afirst));Invariant "safe_10"rpc = NOK -> aerror;This article was processed using theLATEXmacro package with LLNCS style20

برای دانلود رایگان متن کامل این مقاله و بیش از 32 میلیون مقاله دیگر ابتدا ثبت نام کنید

ثبت نام

اگر عضو سایت هستید لطفا وارد حساب کاربری خود شوید

منابع مشابه

A short introduction to two approaches in formal verification of security protocols: model checking and theorem proving

In this paper, we shortly review two formal approaches in verification of security protocols; model checking and theorem proving. Model checking is based on studying the behavior of protocols via generating all different behaviors of a protocol and checking whether the desired goals are satisfied in all instances or not. We investigate Scyther operational semantics as n example of this...

متن کامل

Experiments in Theorem Proving and Model Checking for Protocol Verification

Communication protocols pose interesting and diicult challenges for veriication technologies. The state spaces of interesting protocols are either innnite or too large for nite-state veriication techniques like model checking and state exploration. Theorem proving is also not eeective since the formal correctness proofs of these protocols can be long and complicated. We describe a series of pro...

متن کامل

Machine-assisted Veriication Using Theorem Proving and Model Checking

Theorem proving and model checking are complementary approaches to the veriication of hardware designs and software algorithms. In theorem proving, the veriication task is one of showing that the formal description of the program implies the formal statement of a putative program property, while model checking demonstrates that the program is a model that satisses the putative property. Theorem...

متن کامل

Integrating LTL Model Checking with Automated Theorem Proving

Theorem proving is a general-purpose veriication technique that typically needs to be guided by human insight whereas model checking works in the more constrained domain of essentially nite-state systems but is largely automatic. There are several advantages to integrating the two techniques since theorem proving can be used to compose proofs where individual steps or lemmas have been veriied u...

متن کامل

Linking Theorem Proving and Model - Checking

We present an approach to veriication that combines the strengths of model-checking and theorem proving. We use theorem proving to show a bisimula-tion up to stuttering on a|potentially innnite-state|system. Our characterization of stuttering bisimulation allows us to do such proofs by reasoning only about single steps of the system. We present an on-they method that extracts the reachable quot...

متن کامل

A Survey on Compositional Veri cation

In this survey, we overview several compositional veriication approaches based on model checking, namely compositional minimization, classic assume guarantee reasoning and circular reasoning. We describe details of each of these approaches, and elaborate the general problems with some proposed solutions. We also summarize the advantages and disadvantages of each. In the last section, we give a ...

متن کامل

ذخیره در منابع من


  با ذخیره ی این منبع در منابع من، دسترسی به آن را برای استفاده های بعدی آسان تر کنید

عنوان ژورنال:

دوره   شماره 

صفحات  -

تاریخ انتشار 1996